home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Aminet 1 (Walnut Creek)
/
Aminet - June 1993 [Walnut Creek].iso
/
aminet
/
hard
/
hack
/
omti.lha
/
omti.doc
next >
Wrap
Text File
|
1992-11-25
|
17KB
|
475 lines
O M T I - S O F T W A R E
#=#=#=#=#=#=#=#=#=#=#=#=#
1.0. Hardware
-------------
This archive contains the sources and executeables to a harddisk-device, and
some support programs, who work together with the so called 'omti-harddisk'
interface, which interfaces an PC Omti 5520 / 5527 controller to the Amiga.
This hardware was published by the german computer magazine c't. I haven't
designed a PCB by myself. The c't board must be modified with one more chip:
Omti-Controller Amiga Bus
DREQ ----|)*---+
INTREQ ----|)*---+----- INT2
2/6 74LS05
No, sorry, I don't know the exact pin numbers anymore. I made this
modification to my computer about three years ago and haven't kept the
documentation. Best thing is to solder the 74LS05 on the back of one of the
other chips of the c't harddisk interface.
The c't harddisk interface is *A HACK*! Its controller has no autoconfig
capability and is fixed at 0xee0000.
1.1. The software
This software was written with an Omti 5527 controller. It was never tested
with an Omti 5520 and MFM drives. I'm in doubt, whether it will work without
modifications.
I'm using this software together with two Seagate Drives, a ST238R and a
ST296R drive on an A500. The board of the A500 is built together with the
two disks, a 2 Meg Memory expansion, a serial board and two 3"5 Drives in a
big case. If you're on the UseNet, you may have heard of 'castle.franken.de'
This is this machine... :)
This archive contains sources and executeables to the following programs:
- Boot-Startup-Code for AmigaOS 1.3 and 2.04
- Custom-Bootblocks for AmigaOS 1.3 and 2.04
- example Bootcode
- A Drive-LED Simulator in two versions (only one working :)
- A Low-Level Formatter
- An information-program
- An Disk-installer
- A program to read and to write the boot tracks
- sources for the device
You'll need a directory 'DEVS:OMTI' where various files are stored.
2.0. Outline
------------
It always annoyed me, that, while using harddisks, I had to boot from floppy
disk in order to get the omti.device etc. loaded into memory. I tried to
build a piece of hardware, which contained EPROMs with the boot code, but
this failed miserably. So I started moving another way:
The AmigaOS *MUST* access the floppy drive in any case. It must check,
whether there is a disk in the drive(s) and boot from them, if they're
bootable. Why not write a custom bootblock and use a custom disk layout,
which can boot from the harddisk with just reading the disk-bootblocks.
So the following concept was created:
- Loading the bootblock from floppy disk. It contains a bootstrap-loader, which
is made resident under AmigaOS 1.3 (see below). This one loads the boot-tracks
(normally tracks 1 - 3 on Cyl 0) from the harddisk). This code is checked for
a 'BOOT' label, and if this exists, it is executed.
- Under AmigaOS 1.3, this code mounts the following devices:
- CON
- RAW
- NEWCON
- PAR
- PRT
- RAM
- DFx
- one harddisk
assigns the following Volumes:
- SYS
- LIBS
- DEVS
- FONTS
- C
- L
- S
loads the Devs:System-Configuration
installs the FastFileSystem
loads and installs the omti.device
opens the first CLI Window with NEWCON:
- Under AmigaOS 2.0, this code is more sparse (it needn't to do so much patches
as under AmigaOS 1.3, because many of these things are already done by the OS.
- it just loads and installs the omti.device
- mounts up to four partitions on each of the two possible drives
I also wanted to set up some kind of parameter block, who keeps all
information about the drive. This became Block 0 on Track 0 on Cyl 0 of the
harddisk.
In general, you can say, that the Cyl 0 of a harddisk is reserved for system
useage.
3.0 Bootblocks
--------------
The code for the bootblocks is found in src/bootblock/1.3 and src/bootblock/2.0
3.1. Code for AmigaOS 1.3
-------------------------
This code makes itself resident and reset-able, if you use the 'setpatch R'
option, which is also used for the RAD: ramdisk. It prevents itself from
being overwritten by the flaky reset routine in AmigaOS 1.3
If you use this code, you'll need exactly *ONE* disk access *EVER*. All
further attempts to boot from harddisk are made from this resident bootblock
code.
You can override this by either inserting a bootable disk in drive DF0 or
pressing the left mousebutton while the reset sequence.
3.2 Code for AmigaOS 2.0
------------------------
This code does *NOT* make itself resident. Reason for this was, that I
wanted to insert the reboot code properly into the AmigaOS 2.0 reset
sequence, i.a. after the initalisation but before the boot menu (the boot
menu should show all drives already mounted) but I never managed to get it to
work. Then again I lost interest in writing the resident routines and
dropped them alltogether. So this bootblock must be read for every reset or
you'll see the disk animation.
Nevertheless, this bootblock sets the 'Silent Startup' Bit in
expansion.library, so you'll boot without a window up to the first console
write.
4.0. StartUp-Code
-----------------
*WARNING* YOU MUST CUSTOMIZE THIS CODE FOR YOUR OWN GOOD & HARDDISK!
4.1. StartUp-Code for AmigaOS 1.3
---------------------------------
This code is rather crude and not documented. It relies heavily on the not
documeted features of AmigaOS 1.3 and dos.library. However, it was not
written by me and I'm not willing to support it. Use AmigaOS 2.0.
If you really want to bother someone with this code, ask the author, Michael
Schröder (mlschroe@immd4.informatik.uni-erlangen.de). If he's in good mood,
he may help.
4.2. StartUp-Code for AmigaOS 2.0
---------------------------------
This code first sets up the device (it contains some kind of small relocator)
and binds it into the device-list.
Then it mounts all of your harddisk-partitions. So you don't need any mountlist.
Every harddisk has an entry like this in the boot-code:
part0 dc.b 'DH1',0,0,0,0,0
dc.l 20 ; Boot-Priority
dc.l 0 ; Name of the Drive
dc.l 0 ; Name of the Device
dc.l 0 ; Unit for omti.device (Unit 0)
dc.l 0 ; Flags für OpenDevice
;STRUCTURE DosEnvec
dc.l 16 ; ULONG de_TableSize ; Size of Environment vector
dc.l 128 ; ULONG de_SizeBlock ; in longwords: standard value is 128
dc.l 0 ; ULONG de_SecOrg ; not used; must be 0
dc.l 4 ; ULONG de_Surfaces ; # of heads (surfaces). drive specific
dc.l 1 ; ULONG de_SectorPerBlock ; not used; must be 1
dc.l 26 ; ULONG de_BlocksPerTrack ; blocks per track. drive specific
dc.l 2 ; ULONG de_Reserved ; DOS reserved blocks at start of partition.
dc.l 0 ; ULONG de_PreAlloc ; DOS reserved blocks at end of partition
dc.l 0 ; ULONG de_Interleave ; usually 0
dc.l 1 ; ULONG de_LowCyl ; starting cylinder. typically 0
dc.l 300 ; ULONG de_HighCyl ; max cylinder. drive specific
dc.l 30 ; ULONG de_NumBuffers ; Initial # DOS of buffers.
dc.l 1 ; ULONG de_BufMemType ; type of mem to allocate for buffers
dc.l 256 ; ULONG de_MaxTransfer ; Max number of bytes to transfer at a time
dc.l $fffffffe ; ULONG de_Mask ; Address Mask to block out certain memory
dc.l 0 ; LONG de_BootPri ; Boot priority for autoboot
dc.l $444f5301 ; ULONG de_DosType ; ASCII (HEX) string showing filesystem type;
This is mainly the information, that you'll find in a mountlist entry.
You'll find a little more information in the dos/ includes.
Please don't forget, that Cyl 0 is reserved for the system!
Bootpriority is not yet used. (I doubt if it ever will be)
4.3. How to put startup code on the disk?
-----------------------------------------
This is the most interesting issue for you.
You'll need a good monitor for this. I recommend FMon, written by Michael
Schröder, which you can find in the UseNet Archives (comp.binaries.amiga).
4.3.1. For AmigaOS 1.3
----------------------
Don't do it yourself. You'll need more help that I can give you. Ask
Michael. Use the supplied boottracks for AmigaOS 1.3 as you starting point.
These contain all four boottracks from 0 - 3.
Track layout for AmigaOS 1.3:
0000 - 00FF Parameter-Block / Track 0
3400 - 34FF Basic boot code / Tracks 1 - 3
3500 - 3CFF omti.device
3D00 - 6CFF Fast File System
6D00 - 8AFF NewCon-Handler
8B00 - A6FF Shell-Seg
A700 - AFFF StartUp-Code
B000 - CFFF free
FFS, NewCon and ShellSeg have been *HEAVILY* modified to work with this
layout.
Don't worry if you can't get your system alife with AmigaOS 1.3. Don't use
it. Use AmigaOS 2.0.
4.3.2. For AmigaOS 2.0
----------------------
At first, allocate a memory block of $6800 bytes. This will be your bootracks.
Then, load the omti-device absolute to the offset $2004. *DO NOT RELOCATE!*
The device must be for address $0. The bootcode will relocate it.
The hexdump should look like this:
[...]
1FF0: 00000000 00000000 00000000 00000000 ................
2000: 00000000 70014E75 4AFC0000 00040000 ....p.NuJü......
2010: 077A8004 03000000 006E0000 007A0000 .z.......n...z..
[...]
Load the bootcode to offset 0. It may be relocated, because it contains no
absolute addresses.
The hexdump should look like this:
0000: 424F4F54 43E81FFC 22095881 D3FC0000 BOOTCè.ü".X.Óü..
0010: 00082C79 00000004 20290002 D0812340 ..,y.... )..Ð.#@
0020: 00022029 0006D081 23400006 2029000E .. )..Ð.#@.. )..
[...]
Important is the 'BOOT' in the first four bytes.
Then safe this memory block to a file. It must be exactly 26624 Bytes long.
Then use the supplied 'OmtiWrite' to put the boottrack on the disk. Do this
*AFTER* lowlevel format. Format will supply the Parameter block.
If you set the disk mount entries (see above) correct, you should be able to
boot from harddisk and get your partitions mounted correctly.
5.0. The device
---------------
Look at the code. I can't say much more. It will not work with disks without
PARA block. So format new disks immediately.
The device supports two drives, in fact I'm using it with two drives for
about three years under both, AmigaOS 1.3 and 2.0.
6.0. Support programs
---------------------
6.1. OmtiFormat
---------------
This is the lowlevel formatter for the harddisks. It's quite self explanatory.
You can read Err-Lists from DEVS:omti/ and store them there. So it's a good
idea to have a disk handy, from which you boot before formatting.
An Error-List looks like this:
ERRLIST <- Yes, it's really an ERRLIST
37 <- Number of bad tracks
4,75 <- head, track
4,76
[..]
5,19
5,171
5,172
[..]
5,418
5,441
You can make this list with a text editor and store them into DEVS:omti/ as
'Errorlist.0' and 'Errorlist.1' for unit 0 and 1. You'll find the errorlist
for your drive on a label glued to the drive. (At least with Seagate drives)
You must click on the necessary gadgets to activate certain functions. E.g.
at least unit and steprate must be clicked to be able to use 'Get Parameter
from Harddisk'
The user interface is crude and not written to the C= style guide. I
apologize for it. But then again, it's about three and a half years old.
You can't click Nof WrCyl. These are calculated by subtracting the tracks
needed for error correction tracks.
The formatter can also read and write the PARA blocks on the harddisk. So you
needn't reformat to change e.g. the Autopark Flag.
Parameter blocks are stored as 'ParaBlock.0' and 'ParaBlock.1' in DEVS:Omti/
*WARNING* If you low-level format your drive, you SHOULD DEFINITELY be aware
what you're doing. Drives which you low-level formatted are *EMPTY* and no
force in the world (except a backup) can give you your data back.*
You've been warned!
All other tools are less harmful to your data :)
6.2. OmtiInstall
----------------
This rather simple tool installs the custom bootblocks to boot from unit 0 or
unit 1 on a floppy disk.
It tries to read DEVS:Omti/OmtiBoot.0 or DEVS:Omti/OmtiBoot.1, which should
contain the bootblocks together with checksum and all.
You must create these bootblock files from the executeables with the help of
a monitor, which can also correct the bootblock checksum. Did I mention FMon
yet? Yes? ;)
6.3. OmtiInfo
-------------
This tool reads the PARA block of a harddisk and displays some statistics.
This is how my drives show up:
Parameter fuer Drive 0:
----------------------
Device-Parameter:
Hoechster Zylinder: 614
Hoechster schreib-/lesbarer Zylinder: 614
Write-Precompensation Zylinder: 256
Park-Zylinder: 670
Koepfe: 4
Steprate im uSec: 10
Init-Parameter:
AutoPark aktiv: NEIN
Write-Protect: NEIN
Boot-Parameter:
Boot-LUN: 0
Startkopf fuer Bootspur: 1
Startsektor fuer Bootspur: 0
Startspur fuer Bootspur: 0
Anzahl der geladenen Bloecke: 78
Format-Parameter:
Verwendeter Interleave: 2
Sektoren pro Spur: 26
Sonstiges:
Bruttokapazitaet des Drive: 31.23 MByte = 31980 KByte = 32747520 Byte
Nettokapazitaet des Drive: 31.18 MByte = 31928 KByte = 32694272 Byte
Parameter fuer Drive 1:
----------------------
Device-Parameter:
Hoechster Zylinder: 819
Hoechster schreib-/lesbarer Zylinder: 812
Park-Zylinder: 0
Koepfe: 6
Steprate im uSec: 10
Init-Parameter:
AutoPark aktiv: NEIN
Write-Protect: NEIN
Boot-Parameter:
Boot-LUN: 1
Startkopf fuer Bootspur: 1
Startsektor fuer Bootspur: 0
Startspur fuer Bootspur: 0
Anzahl der geladenen Bloecke: 26
Format-Parameter:
Verwendeter Interleave: 2
Sektoren pro Spur: 26
Sonstiges:
Bruttokapazitaet des Drive: 62.46 MByte = 63960 KByte = 65495040 Byte
Nettokapazitaet des Drive: 61.85 MByte = 63336 KByte = 64856064 Byte
(Yeah, they're old, they're slow, they're hot and they were EXPENSIVE. But
they're still running fine. Why should I change? ;)
6.4. OmtiRead and OmtiWrite
---------------------------
These tools are used to read and write 2.04 compatible boot tracks from the
harddisk and to the harddisk. They both work on track 1 and 2 of the
harddisk (1.3 boottracks are on 1-3).
OmtiWrite may damage your boottrack, but can do no harm to your data.
6.5. OmtiDisplay_Timer and OmtiDisplay_Vector
---------------------------------------------
These tools have the same purpose. Their only difference: OmtiDisplay_Timer
works and OmtiDisplay_Vector crashes. :)
They both simulate the LEDs of the drives in a small window up in the right
corner of the screen. This is useful if you don't have the drive led on your
front panel of if your computer is faaaaar away from the monitor.
If I think about it, there may be only a 'geta4()' missing in .._Vector', but
I'm much too lazy to look at the code again. As I told you, this whole thing
is a hack from the beginning and I do not really want to support it any
longer. But you and you and you asked me about a release. So there.
.._Timer uses the timer-device to poll all 1/10 of a sec. the state of the
drive motors and draw the led symbol. .._Vector should use the callback hook
in the device.
If you get .._Vector to work, tell me. I'll be happy, too.
7.0. And that's a wrap!
-----------------------
At least I think. If you still have followed me up to here (and understood
everything :), I wish you good luck with installing this software. You'll be
rewarded with blinding performance (This thingie is *MUCH* faster than the
original c't device and about 10 % faster that the ALF device).
If you got it to work on your system, tell me. I'll be happy to hear.
You still have questions? Well, ask me. And may the source be with you
(that's why I included it. :)
Erlangen, in the Fall of 1992
Henning